This invention relates to a method for detaching and re-attaching components of a computing process, and in particular for example to such a method for removing parts of the data, program code and execution state of a process and for transferring those parts to secondary or tertiary storage where they may be stored while not needed, before being re-attached to the process when required once more.
In a number of computing environments a large number of processes may be running concurrently on a single machine. This can happen for example in a follow-me computing environment where processes can span multiple user sessions. This results in a large number of processes—some active, some suspended—on a single machine. The presence of such a large number of concurrent processes can place a heavy burden on the resources of the system and can substantially slow down the running speed of the system.
A similar problem can occur in networks involving computing devices that may have limited memory space. Unless the memory space of such devices is used with maximum efficiency, the memory can quickly become overloaded. Minimizing resource usage is therefore imperative.
It would therefore be desirable if it were possible for elements of a computing process that were temporarily not required to be removed from the limited device or network and stored in such a way that they could be re-integrated into the process at a later time when required.
Recent years have seen a number of developments in computing science regarding how elements within a software application are treated and handled. In this context the most basic elements to be found within a software application are data and program modules. Traditional procedural programming paradigms focus on the logic of the software application, so a program is structured based on program modules. One uses the program modules by explicitly supplying to them the data on which they should operate.
More recently there has been a move towards an object-oriented paradigm. In this paradigm, programs are structured around objects, with each object representing an entity in the world being modeled by the software application. Each object manages its own data (state), which are hidden from the external world (other objects and programs). An object in a program interacts with another object by sending it a message to invoke one of its exposed program modules (method). This paradigm imposes better control and protection over internal data, and helps to structure complex applications designed and implemented by a team of programmers. An example of an object-oriented environment can be found in U.S. Pat. No. 5,603,031. This discloses an environment in which new agents (essentially objects) consisting of data and program modules can be sent between machines. However, in the environment of U.S. Pat. No. 5,603,031 a special application code is needed to convert state information into data in the newly created process, and to ensure that the latter begins execution from the right instruction. Since execution state cannot be manipulated directly, it is very tedious, if not impossible, to transfer shared resources within a process to a surrogate. Moreover since the surrogate has a different identity from the original process, shared resources managed externally, such as data locks, cannot be transferred.
While object-oriented paradigm represents a significant advance in software engineering, the data and modules that constitute each object are static. The paradigm is still inadequate for writing programs that must evolve during execution, eg programs that need to pick up, drop, or substitute selected modules. There have been several attempts at overcoming this limitation. For example, work described in U.S. Pat. Nos. 4,954,941, 5,175,828, 5,339,430 and 5,659,751 address techniques for re-linking or re-binding selected software modules dynamically during runtime. Also Microsoft's Win32 provides for explicit mapping and un-mapping of dynamic linked libraries into the address space of a process through the LoadLibrary and FreeLibrary calls. With this prior art, however, the prototype or specification of functions and symbols are fixed beforehand and compiled into application programs. This enables a process to mutate into and back from a surrogate by replacing selected program modules. However, the replacement modules must retain the same function prototypes making coding complicated and unnatural. Also data structures that are not needed by the surrogate remain in memory.
Work has also been done in the area of process checkpointing and recovery. This deals with mechanisms for preserving process state and recovery from machine crashes. The mechanisms operate from outside of the process and the process remains the same upon resumption.